Core modernization and single-resolve dependency management - #14

Hand-authored status/design doc separated from Doxygen output
(docs/build/) and config (docs/Doxyfile, docs/doxygen-awesome-css).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Detailed diff report of core_modernization vs main under docs/design.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Every target ran its own `conan install`, so zerr_core and the wrappers that
link it could be resolved from different profiles. On macOS that produced a
core built at the host SDK's deployment target and wrappers at 10.6, and the
mismatch surfaced only as linker warnings.

Dependencies are now declared once in the root conanfile.txt and generated
into a single build/ folder: core and Max/MSP consume conan_toolchain.cmake,
PureData consumes conandeps.mk. Committed profiles (macos, linux, mingw) pin
the settings that must agree across targets, and recipe revisions are pinned
because both libraries need a ConanCenter revision that supports CMake 4.

build.sh gains a `deps` target and now discards any build tree or installed
archive configured against a different or older toolchain. A CMakeCache
silently ignores a newly passed CMAKE_TOOLCHAIN_FILE -- which is how the
pinned deployment target went missing to begin with -- and an existing
libzerr_core.a is no proof it was built against the toolchain the wrapper is
about to use.

Also fixes three wrapper faults found while reviewing the above:

- mc.zerr.envelopes~ called object_free() before dsp_setup(), so a bad mode
  or config argument reached dsp_free() on an un-set-up t_pxobject
- both envelopes wrappers leaked the ZerrEnvelopes instance when initialize()
  failed; zerr_envelopes~ additionally leaked two strdup'd strings on every
  instantiation, success included
- puredata/Makefile's clean guard matched `make clean all`, which then built
  with the CONAN_* variables empty and produced a cryptic compiler error
  instead of the intended message

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…olution

Resolve conan dependencies once at the repo root

build.sh already selected profiles/mingw for MSYS2/Git Bash hosts, but it never
matched what the Windows CI jobs actually do, so the path it advertised did not
work:

- Pin -G "MinGW Makefiles". Without it CMake picks a Visual Studio generator
  whenever one is installed and compiles with MSVC against a MinGW toolchain.
- Prefer mingw32-make over the MSYS make, as the PureData Windows job does.
- Discard a build tree whose cached CMAKE_GENERATOR disagrees. Passing -G to a
  directory configured by a different generator is a hard CMake error, not a
  warning, so the existing staleness check had to learn about it.
- Compare the cached CMAKE_TOOLCHAIN_FILE against the native path spelling.
  $TOOLCHAIN comes out of `pwd` as /c/Users/..., while the MSYS layer rewrites
  the argument to C:/Users/... on its way to a native CMake -- a verbatim
  compare can never match, and every run would discard the tree and rebuild the
  core.
- Refuse maxmsp on Windows in the target-validation loop rather than inside
  build_maxmsp, because the dispatcher builds the core library before calling
  the per-target function. A .mxe64 needs MSVC, whose ABI cannot link a
  MinGW-built libzerr_core.a.

The Windows path is written to CI parity but has not been exercised on real
hardware. The branches were verified on macOS with a faked host: profile and
generator selection across Darwin/Linux/MINGW/MSYS/CYGWIN, mingw32-make
preference and fallback, guard ordering for single and multi-target invocations,
and that `-c maxmsp` still cleans.

docs/design/dependency-fallbacks.md replaces the USE_SYSTEM_DEPS fallback that
was assessed and declined. Rather than an untested second resolve path, it
records which non-conan routes are viable and what each one breaks: target names
verified against the generated files (conan exposes fftw as fftw::fftw but its
libraries as FFTW3::* components, with fftw3f/fftw3l siblings of the double
precision target we need), static vs shared, YAML_CPP_STATIC_DEFINE living in
two places, the deployment target, and the CMake 4 floor behind the pinned
recipe revisions.

repo-audit §2.3 is corrected: it claimed improve_deps_manage had been fully
re-applied. The superbuild and the system-deps fallback were never ported, both
deliberately, and the branch also carries two regressions worth recording.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>